fix(cli): replace skill installer script with init command#236
fix(cli): replace skill installer script with init command#236cameroncooke merged 4 commits intomainfrom
Conversation
commit: |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
|
Addressed in 9121d78.\n\n- Replaced redundant with so it now carries user-facing labels.\n- Labels now match intent from the old installer flow:\n - -> \n - -> \n- Updated init command tests to assert the new output strings. |
|
Correction: previous comment formatting was mangled by shell interpolation. Addressed in 9121d78.
|
|
Fixed in 99828a1. What changed:
Also added test coverage for uninstall with no auto-detected clients. |
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| if (earlyCommand === 'init') { | ||
| await runInitCommand(); | ||
| return; | ||
| } |
There was a problem hiding this comment.
Bug: The init command is dispatched via runInitCommand() before initSentry() is called, so any errors thrown during initialization will not be reported to Sentry.
Severity: MEDIUM
Suggested Fix
Call initSentry({ mode: 'cli' }) at the beginning of the runInitCommand() function. This will ensure that Sentry is initialized before the command logic is executed, allowing it to capture any subsequent errors, similar to the pattern used in startMcpServer().
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: src/cli.ts#L77-L80
Potential issue: The `init` command is dispatched early via `runInitCommand()` at
`src/cli.ts:77-80`, which bypasses the main Sentry initialization on line 81. Unlike
other commands, `runInitCommand()` does not call `initSentry()` itself. As a result, any
errors thrown during the `init` process (e.g., due to file system issues, missing skill
sources, or user cancellation) will propagate up to the main `catch` block without being
captured by Sentry. This creates a monitoring blind spot for a critical user onboarding
command, preventing developers from being alerted to production failures.
Did we get this right? 👍 / 👎 to inform future reviews.
There was a problem hiding this comment.
Thanks for flagging this. I reviewed the flow and agree there is a small observability gap: init is dispatched before initSentry({ mode: "cli" }), so fatal init-path errors won’t have full Sentry initialization.\n\nThat said, this is low-risk and telemetry-only (it does not change command behavior), and we already print actionable errors to stderr and exit non-zero. Given current PR scope, I’m deferring this rather than expanding the change set.\n\nFollow-up option (if we choose to tighten telemetry): initialize Sentry before init dispatch (or call initSentry inside runInitCommand) and add explicit fatal capture in the top-level catch path.
1 participant
Summary
scripts/install-skill.shflow with a built-inxcodebuildmcp initcommandinitcommandskills/in portable packagingKey changes
src/cli/commands/init.tsand tests insrc/cli/commands/__tests__/init.test.tsinitinsrc/cli.tsearly dispatch andsrc/cli/yargs-app.tshelp/discoveryinittoscripts/check-docs-cli-commands.jsscripts/release.shREADME.mdanddocs/MIGRATION_V2.mdto usexcodebuildmcp initskills/in portable packaging scriptsValidation
src/daemon.ts, no errors)xcodebuildmcp init --printinit --print)brew test+init --print